ontents · Introduction · Objectives · Configuration · Shapes · Controls · Sounds · Scoring · Code Requirements · Report · Deliverables · Grading · Start Small Introduction The Final Project gives you the opportunity to apply the object-oriented software development skills you have acquired during the course to a significant but moderately-sized application. The following sections describe the general behavior of the application, the simulation, and the deliverable requirements for the project. The final project for this class is a built upon your homeworks. You are going to create a very simple version of Asteroids, but with shapes. I will also work through this with you and provide you a working demo on D2L by end of week 8 The template for the project is on D2L under Final Project. Objectives The objective is pretty simple. Create a keyboard driven video game, with you the player in the center of the screen. Shapes will enter the screen and you will need to shoot them. If any of the shapes collide with your ship your game will end. What I will provide: A template GUI to start with. Trapping the keys and bound methods for them. You can find this Configuration Configuration.json is the games overall configuration file. Since this is a first attempt at such a project we may need to add additional parameters. You can use the ShapeParser as an example of how to parse this file. I would recommend you add additional utility methods to the Extractor utility class if needed. You may want to consider a singleton that stores all the configuration data. It will help you not only with design but the ability to hardcode debug values in it instead of having to constantly modify the configuration.json. The configuration file contains only best guesses as to what values to put in. You should adjust them accordingly for development then pick ones that are realistic for final release. Hint: By having slow speeds you can easily validate your game visually. Below are the fields: “game”– The main key for the file. Not used for anything internally. “framespersecond” – int - The number of framespersecond, or the overall game speed. Use this value in Motion.java. Replace the ‘FRAMES_PER_SECOND’ with a call to your Configuration managers method for framespersecond. “shotspeed” – float - The speed at which your shots will travel. Shots are not affected by friction. “forwardthrust” – float - Each tap of the forward thrust increases the player’s x/y speed by 1. Remember in graphics ‘up’ is –y. I will provide you with the algorithms for this. Basically if the nose of the ship is at 0 degrees it’s cos 0 degrees, sin 0 degrees or +1.0x, 0y. If it’s at 45degress, it’s 1/sqrt(2), -1/sqrt(2), and at 0 its 0,-1. Again remember for y it’s inverted. I will double check to make sure this works. "shapes" – float - This is the number of shapes to start with. You could use this or even create a random shape factory that creates a shape at some arbitrary condition or time. “reversethrust” – float - This is the ‘new’ additional feature of ours versus classic Asteroids. While you can rotate around and use forward thrust to slow, we’ll also try this. It’s simply inverting the values of forward thrust and should be a line of code literally. “friction” – float - This is the speed at which the ship slows because of friction in encounters. Try adjust accordingly. “leftright” – float – The amount at which the player ship rotates left or right per key input. “color” – integer - The ships color. “borders” – String - This is how your ship will react when it hits the border, just like homework 3. This will give you a new dimension to the game and comes at no additional work. You may even want to consider additional ‘border’ options like ‘Explode’. That is if you ship touches the border it will be crushed. Shapes shapes.json is the games overall shape file. You can use this to adjust your shapes initial location, speed, etc. You may even want to consider writing a Shape factory that can generate random shapes indefinitely as an alternative. This will give you unlimited play. Everything in the original shapes.json will remain. Additional parameters are: “size” – string - “large”, “medium”, “small”. I would recommend you set all your initial shapes to ‘large’ but you don’t have to if you do your code correctly. The shapes when they are shot go from large to medium to small. When small shapes are shot they disappear. “score” – an integer - the initial score for the object. “multiplier” – an integer – the score for the next object size. Example: Say you create a ‘large’ square worth 10 points and multiplier of 10. Then mediums are worth 100 and smalls would be worth 1000. “children” – an integer – when a shape is shot it will break into smaller objects of the same type. That number of smaller objects is determined by the ‘children’ value. Controls I have provide hooks in main.se450.keyboard to trap various keys. You may add others as you wish. The keys I have implemented are: ‘Q’ – Quits the game. ‘Space’ – Fire. Only plays the sound. You need to do the graphics and logic behind it. I’ll provide ‘hitTest’ methods for you by end of week so you can determine if a shot is hitting a shape (as well as a shape hitting your ship) ‘T’ – Toggle. Toggles or (pauses/resumes) the game Here is what you need to do: ‘1’ – Starts the game. You need to play your player in the center of the screen. Then bring in the shapes from the borders. ‘B’ – HyperSpace. This one simply generates a random area within the boundaries for your ship to ‘teleport’ to. Reentry is dangerous. Use sparingly. This method is a great candidate for TDD. ‘L’ – Rotates the ship counter-clockwise the amount defined by the ‘leftright’ value. Note, this is a continuous tapping at the moment. I haven’t investigated the capability of ‘continuous’ key input yet. ‘R’ – Rotates the ship clockwise the amount defined by the ‘leftright’ value. ‘F’ – Forward thrust. The amount to increase the players speed in the direction of the ships nose. The value is based on the forwardthrust value in the json configuration file. Optional: ‘R’ – Reverse thrust. The amount to reverse the players speed in the direction opposite the ships nose. The value is based on the reversethrust value in the json configuration file. ‘S’ – Shield. Protects the ship from being destroyed by Shapes or borders. 3 uses that last 5 seconds each. When shield is on it should draw a circle around the ship for 5 seconds. If the border value is Explode and the shield is on the ship can either explode, stop, or bounce back. At this point its purely optional. Sounds I have provided 11 of the classic wav files. You should at minimum implement bigexplosion, medium explosion, small explosion, and forward thrust. I have implemented fire.wav as an example for you. I have also provided the sound object to play the music for you. You need to think about how you want to manage it. You might not need to ‘new’ a sound object everytime you want to play it, you could probably create a Singleton that manages an instance each of all the sounds and just provide wrapper methods to the application to play the appropriate sound. Optional sounds for saucers, slow and fast music are available that you could implement. There currently isn’t any ‘enemy’ ship, but if you get board you can create it. Given this is the first time for this project the scope is not well understood. Scoring Per the values you set in your shapes.json file, use those values to update the JTextArea of the main GUI. You need to think about how you want to do this. You can have the main application become a ‘ScoreObserver’ or you could even override the JTextArea like I did JPanel and have it or implement a ‘ScoreObserver’. It would be easier that trying to pass around references everywhere. Code Requirements The application must be written in Java. Please use 1.8 or higher You should must write unit tests for at least two classes. The application must use at least three different design patterns that we have discussed in class. You will be expected to demonstrate and explain the patterns in your final written description. Report Forty-five percent / 45% of your grade is based is based on your report, UML class diagrams and Javadocs. 15% is for the report, 15% for your class diagrams, and 15% for your Javadocs respectively. Although no specific style guidelines are being enforced, the report must be presented in a neat, legible, and consistent format. The report must be in doc format. Diagrams should be created in Visio. If you do not have access to Visio use another diagramming tool and export your diagram as common image format. The diagrams should conform to the UML notational conventions presented in class. The written report should be structured as follows: Title pagewith your name at the top. Discussion of your solution. Give an overview of your solution, the challenges, and what areas you completed and what areas you did not. Detail any needed setup such as configuration files, what keys you added or changed, and any other information need to use the application. Discussion of patterns. Indicate the design patterns used in your project. Detail at least 3. For each pattern, note the specific problem in your project that the pattern solved. Also indicate the classes involved and briefly discuss the implementation of the pattern. You may use the patterns such as Singleton, Observer, Factory. UML Class diagram. Include the overall UML class diagram for your application. You only need to detail the important details. Create high level classes and their dependencies. Be sure to show multiplicity, important class relationships, utility classes, interfaces, etc. Show attributes and methods only if they are crucial to understanding the class relations. Think of your audience as a business leader with some technical knowledge rather than an engineer implementing the design.Please do not use tools that automatically generate diagrams from your code. They are unreadable. Unreadable, bloated UML diagrams are worthless and will be graded accordingly. Create Javadocs for the most important classes in your application. Make sure that the javadocs can be navigated through a browser. Create meaningful, concise information. Deliverables Due March 13, 2017 by 11:30pm Submit a zip file of your project and report. Place the report in your project folder at the top level, naming it Report. For the project you must include any important libraries and configuration files that project depends on. You do not need to include the bin folder. Once you have these files in your project folder, right click on your project folder and Compress (Mac) or Send To Compressed (Windows). Now take this zip file and submit it to D2L. Any submission not conforming to this format will lose 5%. It’s time critical to alleviate any issues with project structures in order to get all the finals and final projects graded by the day grades are due. Test your zip file by unzipping it into a fresh directory, import it into Eclipse and make sure everything works. Projects will be graded accordingly if they cannot be unzipped and imported easily into Eclipse. Grading Grading will follow these guidelines: Application: 55% Satisfies requirements Correctness (compilation & execution) Quality of code & documentation Adherence to standards Report: 55% Satisfies requirements Correctness (compilation & execution) Quality of code & documentation Adherence to standards Start Small Start with one step at a time. Think first about your design and what you need to accomplish the project. Save your report and javadocs for last since your code will be changing. Pick when to practice test drive development and add unit tests. Unit tests are a great way to ensure you aren’t breaking exist code. Also refactor your code as you progress and realize better ways to solve the objective. To get started with the implementation, I’d recommend first getting the shapedroids and enemy ship to properly draw. Next work on implementing the keyboard and controlling your players ship. Figure out first how to place it in the screen then control it. You know the dimensions of the screen, the player ship simply needs place at the center. Once all that is working add sound. The sound files and player will be provided, all you need to consider is how you want to leverage it. You may consider a singleton class with methods to play each sound or you may simply want to create instance of each sound as needed. Lastly, I will provide ‘hittest’ and ‘rotation’ code for your shapes and ship. The hittest will tell you if a shape and ship collided, or if a shot hit a shape. Once you can determine this, all you need to do is play the proper explosion noise, update the score accordingly, and generate a smaller shape if needed. Optional: For cool effects, when the smallest shape is hit by the ships fire it will go away, but you can create an ‘explosion’ object. You can use a gif or create a class that generates some random fading points. For the ship I’d recommend take the 4 lines of your ship and ‘breaking them up’ by creating 4 line objects with random x